Many production software systems include a large number of services and components, each having many configuration settings. In complex systems, the business logic for each service and/or component is typically kept in a configuration file and must be carefully defined to satisfy various requirements, such as regulatory compliance. A system operator is tasked with correctly configuring long-running services to minimize service interruptions. When a service fails for bad configuration, the operator must quickly identify the root cause—that is, which recent configuration changes caused the failure—and reconfigure the system to correct the problem.
Software configuration systems are known. A typical approach is to define a software system's configuration using key/value pairs, which can be encoded in XML, JSON, or simple text property files, such as Java property files. Configuration keys are literal values used in both the configuration files and the software. A configuration setting may a have default value defined in the software; that is, if the setting is not explicitly defined in the configuration file, the default value is used. Existing configuration systems may provide an application programming interface (API) through which software components can retrieve the configuration settings.
As those skilled in the art will appreciate, several problems commonly appear with existing software configuration systems. Existing systems are prone to operator error. For example, if a configuration key is misspelled, a default value may be used instead, unbeknownst to the operator. Another common problem is that if a key appears multiple times within a configuration file, all but one of the corresponding values will be ignored, leading to unintended results. Duplicate keys also decrease the conciseness and readability of a configuration file.
Many existing configuration systems require a service to be restarted to change any of its configuration settings. Moreover, even if a service supports dynamic reconfiguration (i.e. without needing to restart the service), certain settings may be de facto immutable. For example, in certain applications, network configuration settings cannot be changed without causing unacceptable service interrupts and are, therefore, treated as immutable. Generally, any configuration value used during initialization is de facto immutable.
Existing configuration systems typically lack adequate tools to debug/investigate configuration problems. When a service or component is misconfigured, it can be difficult to determine how it ended up in such a state. Operators may resort to manually versioning a configuration file before making changes and comparing versions to identify the root cause (i.e. bad configuration). Likewise, many existing systems do not provide rollback capability, instead requiring operators to manually revert bad configuration settings.
Some existing configuration systems use XML schemas to solve some of these problems. For example, XML schemas can be used to prevent misspelled and duplicate configuration keys. However, using XML schemas comes at a high cost: all keys must be maintained in a schema definition as well as in the software component code that uses the corresponding configuration settings. If the schema definition and code are not in sync, the system will either reject good configuration or accept bad configuration.